New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add assertions signature for TypeScript #10543
add assertions signature for TypeScript #10543
Conversation
fields: { | ||
assertsModifier: validateOptionalType("TSAssertsKeyword"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be a boolean, since the only needed information is if it is present or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was following the TypeScript AST.
But I understand Babel AST doesn't have to be the same as Typescript AST.
@@ -904,21 +904,34 @@ export default (superClass: Class<Parser>): Class<Parser> => | |||
const t: N.TsTypeAnnotation = this.startNode(); | |||
this.expect(returnToken); | |||
|
|||
const assertsModifier = this.tsTryParse( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this could be parser without using tryParse
: it would be possible to parse the assert
identifier and then convert it to a type annotation if the next token is not another identifier.
On the other hand, we use tryParse
everywhere when parsing TypeScript. I think that it's better to be consistent here, and then the whole TS parser can be optimized on other PRs.
@@ -73,12 +73,12 @@ | |||
}, | |||
"typeAnnotation": { | |||
"type": "TSTypePredicate", | |||
"start": 10, | |||
"start": 8, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
The CircleCI failure is unrelated and already fixed on master. |
544d494
to
128cd3d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I'm reviewing this because of this: https://babeljs.slack.com/archives/C062RC35M/p1571345121030900)
Having read the blog post on TypeScript 3.7 and played around with it in the local REPL, this seems sane to me.
Hi there! We on Could we look to align the AST representations? I got alerted to this via typescript-eslint/typescript-eslint#1158. |
I'm 100% ok with it. We are going to release a new Babel version soon; would you be able to prepare a quick PR? |
I'll do it |
@thorn0 thanks! |
Should I make changes to the docs manually, or wait for babel/website#2080?